home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14330 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.8 KB
  1. Path: sun630.bentley.com!usenet
  2. From: Philip McGraw <Philip.McGraw@Bentley.com>
  3. Newsgroups: comp.lang.c++,comp.os.ms-windows.programmer.win32
  4. Subject: Re: VC++ 4.0 memory allocation slower than in 2.x!!!
  5. Date: Fri, 29 Mar 1996 15:52:48 -0500
  6. Organization: Bentley Systems
  7. Message-ID: <315C4DA0.30C@Bentley.com>
  8. References: <alanDozpsy.Kn6@netcom.com>
  9. NNTP-Posting-Host: dhcp6243.bentley.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0GoldB1 (WinNT; I)
  14.  
  15. Robert Alan Wright wrote:
  16.  
  17. > I recently posted a request for help in determining why a program which
  18. > was simply recompiled on VC++4.0 suddenly ran 3 times slower than the
  19. > same one did under VC++ 2.0.
  20.  
  21. > I went through all the usual steps of making sure that I had the right
  22. > compiler/link settings and even built my own version of the MFC
  23. > libraries to make sure they were fully optimized.
  24.  
  25. > Upon further profiling and other exploration, I found out the problem:
  26. > THE VC++ 4.0 MEMORY ALLOCATION ROUTINES ARE WAY SLOWER!!!
  27.  
  28. The VC 4.0 C runtime libraries use HeapAlloc and HeapFree instead of the suballocation from 
  29. VirtualAlloc'ed memory that was used in VC 2.x.  You can rebuild the VC 4.0 runtime libraries to 
  30. use the old scheme by setting WINHEAP = NO on line 78 of the makefile (and also changing the lib 
  31. and dll names on lines 19-22 from _sample_ to msvcrt40 and _sampld_ to msvcr40d).  I'd be 
  32. interested in hearing how much this speeds up your program's performance.  Of course, you cannot 
  33. ship modified DLLs with the same name as the standard ones, but this is just an experiment anyway.
  34.  
  35. > I don't understand how this can be, but I switched from using the
  36. > Microsoft malloc/realloc routines to my own versions, and now I
  37. > get about the same performance from the app that I used to.
  38.  
  39. Did you use a suballocation scheme similar to the one used by the VC 2.0 library?
  40.  
  41. > As best I can tell, the new realloc routine is about 10 TIMES SLOWER
  42. > than the old one, and malloc is also slower. At this point, I
  43. > have replaced the use of almost all Microsoft MFC classes as well as
  44. > C/C++ runtime routines in order to get decent performance. I am quite
  45. > disgusted in the apparent low quality of their implementations.
  46.  
  47. > Can anyone offer any more rational explanation for this than that
  48. > Microsoft has horrible quality control? I'm having a hard time
  49. > believing they could do screw up this badly.
  50.  
  51. The only explanation I can think of is that the Win32 heap routines might have been considered more 
  52. reliable or debuggable than the runtime suballocation routines.  Or, they may have just decided to 
  53. let the operating system handle something that the C runtime used to handle.  I have noticed that 
  54. the default allocator for OLE appears to be these same Win32 heap routines.  Maybe that enters into 
  55. their decision also?
  56.  
  57. Philip McGraw
  58.